fix(tbench2_env): a missing reward.txt is a scoring error, not reward 0.0 - #1025

Follow-up to #1012, closing the last gap where an infrastructure failure could masquerade as a task failure (spotted by @Shi-Dong reviewing the downstream consumer).

What

When the canonical harness runs but no verdict is ever written — tests/test.sh crashed or was killed before its verifier wrote /logs/verifier/reward.txt (e.g. the uvx toolchain download failed, or the in-shell timeout fired) — evaluate previously returned reward 0.0 with the normal canonical-harness info, byte-for-byte indistinguishable from tests genuinely failing.

Now _parse_canonical_reward returns None for an absent/empty/non-numeric verdict and both callers (local + docker mode, via a shared _require_canonical_verdict) raise: step() reports it through its existing error path — observation.error set, reward=None, episode keeps its session — with the test.sh log tail in the message for diagnosis. Verify-window cleanup still runs (covered by tests in both modes).

Why it matters

RL consumers must be able to drop a no-verdict episode: ingesting it as 0.0 injects a false negative into training that no client-side check can catch (the reply looked completely valid). A genuine test failure still scores 0.0 — test.sh's verifier writes reward.txt = 0 in that case, so the only replies that now error are ones where the verifier never ran to completion.

Behavior change

Only the no-verdict edge case: evaluate replies that used to be a silent 0.0 are now an explicit scoring error. Genuine passes/failures and the pytest-fallback path (which scores by exit code and always has one) are unchanged.

Validation

pytest tests/envs/test_tbench2_env.py → 26 passed: two new tests (local + docker) assert an empty reward marker raises RuntimeError("produced no verdict") and that staged verifier assets are still wiped on the error path.

🤖 Generated with Claude Code